[BoundsSafety][LLDB] Implement instrumentation plugin for -fbounds-safety soft traps #11835

delcypher · 2025-11-14T23:55:39Z

This patch implements an instrumentation plugin for the
-fbounds-safety soft trap mode first implemented in
#11645 (rdar://158088757).

The current implementation of -fbounds-safety traps works by emitting
calls to runtime functions intended to log the occurrence of a soft trap.
While the user could just set a breakpoint of these functions the
instrumentation plugin sets it automatically and provides several
additional features:

When debug info is available:

It adjusts the stop reason to be the reason for trapping. This is
extracted from the artificial frame in the debug info (similar to
-fbounds-safety hard traps).
It adjusts the selected frame to be the frame where the soft trap
occurred.

When debug info is not available:

For the call-with-str soft trap mode the soft trap reason is
read from the first argument register.
For the call-minimal soft trap mode the stop reason is adjusted
to note its a bounds check failure but does not give further
information because none is available.
In this situation the selected frame is not adjusted because in
this mode the user will be looking at assembly and adjusting the
frame makes things confusing.

This patch includes shell and api tests. The shell tests seemed like the
best way to test behavior when debug info is missing because those tests
make it easy to disable building with debug info completely.

rdar://163230807

This refactors the soft trap runtime test so the soft trap runtime implementation exists in its own file. This has several advantages: * It let's the runtime be built without debug info which will be the common case uses hit * It prevents the risk of infinite recursion because it isn't safe to build the soft trap runtime with -fbounds-safety soft trap mode enabled.

delcypher · 2025-11-15T00:23:52Z

@swift-ci test

delcypher · 2025-11-15T00:24:03Z

@swift-ci test llvm

…fety soft traps This patch implements an instrumentation plugin for the `-fbounds-safety` soft trap mode first implemented in swiftlang#11645 (rdar://158088757). The current implementation of -fbounds-safety traps works by emitting calls to runtime functions intended to log the occurrence of a soft trap. While the user could just set a breakpoint of these functions the instrumentation plugin sets it automatically and provides several additional features: When debug info is available: * It adjusts the stop reason to be the reason for trapping. This is extracted from the artificial frame in the debug info (similar to -fbounds-safety hard traps). * It adjusts the selected frame to be the frame where the soft trap occurred. When debug info is not available: * For the `call-with-str` soft trap mode the soft trap reason is read from the first argument register. * For the `call-minimal` soft trap mode the stop reason is adjusted to note its a bounds check failure but does not give further information because none is available. * In this situation the selected frame is not adjusted because in this mode the user will be looking at assembly and adjusting the frame makes things confusing. This patch includes shell and api tests. The shell tests seemed like the best way to test behavior when debug info is missing because those tests make it easy to disable building with debug info completely. rdar://163230807

delcypher · 2025-11-15T02:09:42Z

@swift-ci test

delcypher · 2025-11-15T02:09:49Z

@swift-ci test llvm

delcypher · 2025-11-16T16:57:47Z

Windows failure looks completely unrelated to this PR:

21:30:12  C:\Program Files\CMake\bin\cmake.exe -B T:\x86_64-unknown-windows-msvc\DocC -S C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\swift-docc -G Ninja -D ArgumentParser_DIR=T:/x86_64-unknown-windows-msvc/ArgumentParser/cmake/modules -D BUILD_SHARED_LIBS=YES -D CMAKE_BUILD_TYPE=Release -D CMAKE_C_COMPILER=T:/5/bin/clang-cl.exe -D CMAKE_C_COMPILER_TARGET=x86_64-unknown-windows-msvc -D CMAKE_C_FLAGS=/GS- /Gw /Gy /Oy /Oi /Zc:inline -D CMAKE_EXE_LINKER_FLAGS=/INCREMENTAL:NO /OPT:REF /OPT:ICF -D CMAKE_FIND_PACKAGE_PREFER_CONFIG=YES -D CMAKE_INSTALL_PREFIX=T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr -D CMAKE_MAKE_PROGRAM=C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe -D CMAKE_SHARED_LINKER_FLAGS=/INCREMENTAL:NO /OPT:REF /OPT:ICF -D CMAKE_STATIC_LIBRARY_PREFIX_Swift=lib -D CMAKE_Swift_COMPILER=T:/5/bin/swiftc.exe -D CMAKE_Swift_COMPILER_TARGET=x86_64-unknown-windows-msvc -D CMAKE_Swift_COMPILER_WORKS=YES -D CMAKE_Swift_FLAGS=-sdk \"T:/Program Files/Swift/Platforms/Windows.platform/Developer/SDKs/Windows.sdk\" -gnone -Xlinker /INCREMENTAL:NO -Xlinker /OPT:REF -Xlinker /OPT:ICF -D CMAKE_Swift_FLAGS_RELEASE=-O -D CMAKE_Swift_FLAGS_RELWITHDEBINFO=-O -D cmark-gfm_DIR=T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/cmake -D LMDB_DIR=T:/x86_64-unknown-windows-msvc/LMDB/cmake/modules -D SwiftASN1_DIR=T:/x86_64-unknown-windows-msvc/ASN1/cmake/modules -D SwiftCrypto_DIR=T:/x86_64-unknown-windows-msvc/Crypto/cmake/modules -D SwiftMarkdown_DIR=T:/x86_64-unknown-windows-msvc/Markdown/cmake/modules -D SymbolKit_DIR=T:/x86_64-unknown-windows-msvc/SymbolKit/cmake/modules
21:30:12  -- The C compiler identification is Clang 21.1.6 with MSVC-like command-line
21:30:12  -- The Swift compiler identification is Apple 6.3
21:30:13  -- Detecting C compiler ABI info
21:30:13  -- Detecting C compiler ABI info - done
21:30:13  -- Check for working C compiler: T:/5/bin/clang-cl.exe - skipped
21:30:13  -- Detecting C compile features
21:30:13  -- Detecting C compile features - done
21:30:13  CMake Error at Sources/CMakeLists.txt:11 (add_subdirectory):
21:30:13    The source directory
21:30:13  
21:30:13      C:/Users/swift-ci/jenkins/workspace/apple-llvm-project-pull-request-windows/swift-docc/Sources/SwiftDocCUtilities
21:30:13  
21:30:13    does not contain a CMakeLists.txt file.
21:30:13  
21:30:13  
21:30:13  -- Configuring incomplete, errors occurred!
21:30:13  Error: Error: cmake.exe exited with code 1.

likely caused by swiftlang/swift-docc#1331. Looks like swiftlang/swift-docc#1352 is out to revert this change.

delcypher · 2025-11-17T18:20:38Z

@swift-ci please test windows platform

jimingham · 2025-11-17T22:02:17Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    case ArchSpec::eCore_x86_32_i686:
+      // Technically some x86 calling conventions do use a register for
+      // passing the first argument but let's ignore that for now.
+      return {};


Would it be worth explaining here that you can't get the information for this architecture? Otherwise the person receiving this report might waste time trying to figure out why this wasn't working in their particular case?

If LLDB has a clean way of communicating this to the user I'm willing to use it (e.g. some kind of diagnostic system). At the moment is seems like the only thing I can do is shoehorn the failure into the trap reason message and I think that would be confusing. E.g.:

stop reason = Soft Bounds check failed: Cannot determine trap reason on x86 architecture when debug info is missing

The Cannot determ... part of the message is supposed to be read as the specific reason for trapping normally. Reusing it here to explain why the trap reason couldn't be determined seems a bit confusing.

Ideally what is something like:

stop reason = Soft Bounds check failed note: Cannot determine trap reason on x86 architecture when debug info is missing

but I don't think anything like this exists today.

You can write warning messages directly by writing to the stream returned by Debugger::GetAsyncErrorStream, or you can post a warning event using Debugger::ReportWarning. I think posting a warning event is currently in favor.

jimingham · 2025-11-17T22:03:25Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    auto process = thread_sp->GetProcess();
+    if (!process)
+      return {};
+    switch (process->GetTarget().GetArchitecture().GetCore()) {


Not sure you need to do this for this commit, but it would be clearer if the architecture told you whether it uses registers for argument passing, than having to hard code it here.

I can file a github issue for this. Should this go to the upstream LLVM issue tracker or the Swift issue tracker?

llvm issue tracker, this is architecture and not swift specific.

jimingham · 2025-11-17T22:05:03Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    // Examine the register for the first argument
+    auto *arg0_info = rc->GetRegisterInfo(
+        lldb::RegisterKind::eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1);
+    if (!arg0_info)


Along this process there are a bunch of places where it could fail. It might help your sanity later on if you logged where the failure occurs. Then when this is failing on a machine or for a process you can't get access to you have more of a chance of figuring out what went wrong.

What channel should I use? Presumably you mean logging code like this (first thing I found when greping for LLDB_LOG) ?

Log *log = GetLog(LLDBLog::API); LLDB_LOGF(log, "SBDebugger(%p)::CreateTarget (filename=\"%s\", triple=%s, " "platform_name=%s, add_dependent_modules=%u, error=%s) => " "SBTarget(%p)", static_cast<void *>(m_opaque_sp.get()), filename, target_triple, platform_name, add_dependent_modules, sb_error.GetCString(), static_cast<void *>(target_sp.get()));

TIL, there isn't an instrumentation runtime log channel, which there really should be. So maybe better to do this as a follow-on.

jimingham · 2025-11-17T22:09:35Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+  return lldb::eInstrumentationRuntimeTypeBoundsSafety;
+}
+
+const RegularExpression &


Julian just added a InstrumentationRuntime::MatchAllModules. You still need to override this function but if you also override MatchAllModules to return true, we won't waste time pointlessly trying an empty regex against all the libraries.

The override for MatchAllModules is declared in the header for InstrumentationRuntimeBoundsSafety

delcypher · 2025-11-17T22:29:52Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+  return lldb::eInstrumentationRuntimeTypeBoundsSafety;
+}
+
+const RegularExpression &


The override for MatchAllModules is declared in the header for InstrumentationRuntimeBoundsSafety

delcypher · 2025-11-17T22:30:11Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.h

+                                  lldb::user_id_t break_id,
+                                  lldb::user_id_t break_loc_id);
+
+  bool MatchAllModules() override { return true; }


@jimingham The override is here. That should be sufficient right?

Ah, missed it. Yes, that's good.

delcypher · 2025-11-17T22:32:19Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    // Examine the register for the first argument
+    auto *arg0_info = rc->GetRegisterInfo(
+        lldb::RegisterKind::eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1);
+    if (!arg0_info)


What channel should I use? Presumably you mean logging code like this (first thing I found when greping for LLDB_LOG) ?

Log *log = GetLog(LLDBLog::API); LLDB_LOGF(log, "SBDebugger(%p)::CreateTarget (filename=\"%s\", triple=%s, " "platform_name=%s, add_dependent_modules=%u, error=%s) => " "SBTarget(%p)", static_cast<void *>(m_opaque_sp.get()), filename, target_triple, platform_name, add_dependent_modules, sb_error.GetCString(), static_cast<void *>(target_sp.get()));

delcypher · 2025-11-17T22:33:25Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    auto process = thread_sp->GetProcess();
+    if (!process)
+      return {};
+    switch (process->GetTarget().GetArchitecture().GetCore()) {


I can file a github issue for this. Should this go to the upstream LLVM issue tracker or the Swift issue tracker?

delcypher · 2025-11-17T22:39:22Z

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

+    case ArchSpec::eCore_x86_32_i686:
+      // Technically some x86 calling conventions do use a register for
+      // passing the first argument but let's ignore that for now.
+      return {};


If LLDB has a clean way of communicating this to the user I'm willing to use it (e.g. some kind of diagnostic system). At the moment is seems like the only thing I can do is shoehorn the failure into the trap reason message and I think that would be confusing. E.g.:

stop reason = Soft Bounds check failed: Cannot determine trap reason on x86 architecture when debug info is missing

The Cannot determ... part of the message is supposed to be read as the specific reason for trapping normally. Reusing it here to explain why the trap reason couldn't be determined seems a bit confusing.

Ideally what is something like:

stop reason = Soft Bounds check failed note: Cannot determine trap reason on x86 architecture when debug info is missing

but I don't think anything like this exists today.

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp

jimingham · 2025-11-17T23:05:07Z

lldb/source/Plugins/InstrumentationRuntime/CMakeLists.txt


 add_subdirectory(ASan)
 add_subdirectory(ASanLibsanitizers)
+# TO_UPSTREAM(BoundsSafety) ON


What's this for?

This is a convention we follow for -fbounds-safety code. It's mostly useful for people resolving merge conflicts so they can clearly see what the code causing the conflict is for.

If you would prefer to not have it I can remove it but personally I find is useful.

In this context it just leaves me confused why BoundsSafety is special in this regard? Why isn't this around other InstrumentationRuntimes, what does it do, etc.
But also, I just did

find . -type f -exec grep TO_UPSTREAM {} +

at the top-level llvm-project directory and got no hits. This certainly shouldn't be the first - unexplained - instance of it.

lldb/test/API/lang/BoundsSafety/soft_trap/TestBoundsSafetyInstrumentationPlugin.py

…tationPlugin.py`

delcypher requested review from hnrklssn, jimingham, medismailben, patrykstefanski and rapidsna November 14, 2025 23:55

delcypher self-assigned this Nov 14, 2025

delcypher requested a review from JDevlieghere as a code owner November 14, 2025 23:55

delcypher added the clang:bounds-safety Issue relating to the experimental -fbounds-safety feature in Clang label Nov 14, 2025

delcypher requested review from Michael137 and adrian-prantl November 14, 2025 23:56

delcypher force-pushed the dliew/rdar-163230807-wip branch from f7206d3 to a15e413 Compare November 15, 2025 00:22

delcypher force-pushed the dliew/rdar-163230807-wip branch from a15e413 to c8af09b Compare November 15, 2025 02:09

jimingham reviewed Nov 17, 2025

View reviewed changes

delcypher commented Nov 17, 2025

View reviewed changes

jimingham reviewed Nov 17, 2025

View reviewed changes

lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp Show resolved Hide resolved

jimingham reviewed Nov 17, 2025

View reviewed changes

lldb/test/API/lang/BoundsSafety/soft_trap/TestBoundsSafetyInstrumentationPlugin.py Outdated Show resolved Hide resolved

jimingham reviewed Nov 17, 2025

View reviewed changes

lldb/test/API/lang/BoundsSafety/soft_trap/TestBoundsSafetyInstrumentationPlugin.py Outdated Show resolved Hide resolved

jimingham reviewed Nov 17, 2025

View reviewed changes

lldb/test/API/lang/BoundsSafety/soft_trap/TestBoundsSafetyInstrumentationPlugin.py Outdated Show resolved Hide resolved

delcypher added 2 commits November 17, 2025 16:30

Clean up getting the target and process in `TestBoundsSafetyInstrumen…

41aed56

…tationPlugin.py`

Check the breakpoint has resolved locations

3c3ccb0

[BoundsSafety][LLDB] Implement instrumentation plugin for -fbounds-safety soft traps #11835

Are you sure you want to change the base?

[BoundsSafety][LLDB] Implement instrumentation plugin for -fbounds-safety soft traps #11835

Conversation

delcypher commented Nov 14, 2025

Uh oh!

delcypher commented Nov 15, 2025

Uh oh!

delcypher commented Nov 15, 2025

Uh oh!

delcypher commented Nov 15, 2025

Uh oh!

delcypher commented Nov 15, 2025

Uh oh!

delcypher commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

delcypher commented Nov 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

delcypher Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimingham Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

delcypher Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

delcypher commented Nov 16, 2025 •

edited

Loading

delcypher Nov 17, 2025 •

edited

Loading

jimingham Nov 17, 2025 •

edited

Loading

delcypher Nov 17, 2025 •

edited

Loading